System and Method for Sharing Web Perfomance Data

ABSTRACT

A monitoring system is provided that allows owners of monitoring accounts to share web monitoring data collected under the direction of the monitoring account. Account owners are able to interact with the monitoring system to identify recipient accounts for shared web monitoring data and apply permissions at a granular level so that portions of monitored data can be shared with varying permission levels. Grouping can also be employed by an account owner to facilitate efficient sharing of monitoring data to many recipient accounts. The monitoring system also provides analysis utilities that can be used by a recipient account to aggregate shared with owned data and generate related reports as desired.

RELATED APPLICATION

The present application is a continuation of U.S. patent applicationSer. No. 13/085,323 filed 12 Apr. 2011 and issued as U.S. Pat. No.8,224,959 on 17 Jul. 2012, which is a continuation of U.S. patentapplication Ser. No. 12/253,652 filed 17 Oct. 2008 and issued as U.S.Pat. No. 7,925,747 on 12 Apr. 2011, which claims priority to U.S.provisional patent application Ser. No. 60/981,063 filed 18 Oct. 2007,each of which is incorporated herein by reference in its entirety.

BACKGROUND

1. Field of the Invention

The present invention is generally related to website monitoring andmore specifically related to selectively sharing data obtained fromperforming such monitoring.

2. Related Art

In the current state of the art of web performance monitoring, partiesinterested in monitoring a particular website, web application, webservice, web API, or in general monitoring a target, setup an accountwith a provider of such monitoring services in order to obtain thedesired data. Owners of these accounts monitor one or more targetsthrough the service provider regardless of whether another account owneris already monitoring the same target. This results in significantredundant monitoring and generates data with various degrees of accuracyfor the same target, giving rise to the problem of which set of data istruly accurate and valid.

Currently, there are two different well-known ways to share webperformance monitoring data. One possibility is to give anotherinterested party access to an owner's monitoring account by providingthe interested party with certain login information such as a user nameand password (“credentials”) for the owner's account. Anotherpossibility is to give the interested party one or more reports of thecollected monitoring data.

In the former case, a high degree of trust must be present between theparties sharing the data, since the recipient of the credentials willhave full access to the owner's accounts. The high degree of trustrequirement makes this method unsuitable for most situations.

In the latter case, reports are limited in the sense that they lack theanalysis tools usually provided with monitoring accounts. Moreover,creating an integrated report one party's monitoring data combined withthe other party's monitoring data becomes tedious, as two different datasources need to be reconciled in order for both sets of data to beviewed, examined, and correlated into one or more reports.

Therefore, what is needed is a system and method that overcomes thesesignificant problems found in the conventional systems as describedabove.

SUMMARY

Accordingly, described herein is are systems and methods that addressthe aforementioned issues by allowing owners of monitoring accounts to:(1) share monitoring data with one another seamlessly and securely,providing interested parties with access to desired monitoring data anddata analysis tools; and (2) use a flexible organization and securitymechanism to selectively specify the data to be shared and theauthorized recipients.

A web performance monitoring system allows a web monitoring account thathas used the services of the web performance monitoring system tocollect a variety of monitoring data to share that collected data withanother web monitoring account even though the two web monitoringaccounts are not owned by the same individual or organization.

The owner account is enabled to provide data access to a recipientaccount even though the accounts are completely independent in terms ofdata collection parameters, collected monitoring data, and rights toview the collected data and view and/or modify the data collectionparameters. The owner account is able to identify a recipient accountthat will be granted access to certain monitoring data collected onbehalf of the owner account; identify what monitoring data or portionthereof is to be shared to each recipient account; assign certainpermissions to the monitoring data or portion thereof. The monitoringsystem attends to the delivery of the monitoring data shared with therecipient account by the owner account.

Other features and advantages of the present invention will become morereadily apparent to those of ordinary skill in the art after reviewingthe following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The details of the present invention, both as to its structure andoperation, may be gleaned in part by study of the accompanying drawings,in which like reference numerals refer to like parts, and in which:

FIG. 1 is a network diagram illustrating an example web performancemonitoring data sharing system according to an embodiment of the presentinvention.

FIG. 2 is a block diagram illustrating a web performance monitoringaccount, according to an embodiment of the present invention.

FIG. 3 is a block diagram illustrating a web performance monitoringmodule, according to an embodiment of the present invention.

FIG. 4 is a block diagram illustrating data sharing as performed withina controlling server, according to an embodiment of the presentinvention.

FIG. 5 is a flow diagram illustrating an example of the process ofsharing website uptime and performance data between two monitoringaccounts according to an embodiment of the present invention.

FIG. 6 is a block diagram illustrating the data owner account's view ofthe recipient accounts it has shared data with.

FIG. 7 is a block diagram illustrating the recipient account's view ofthe owner accounts that have shared data with it.

FIG. 8 is a block diagram detailing an example of a share between twoaccounts, as well as the sharing parameters associated with it,according to an embodiment of the present invention.

FIG. 9 is a block diagram illustrating a monitoring account that isacting as both a data owner and data recipient, according to anembodiment of the present invention.

FIG. 10 is a block diagram illustrating the enumeration method fororganizing data to be shared, according to an embodiment of the presentinvention.

FIG. 11 is a block diagram illustrating the group method for organizingdata to be shared, according to an embodiment of the present invention.

FIG. 12 is a block diagram illustrating sharing being performed withinthe group method for data organization, according to an embodiment ofthe present invention.

FIG. 13 is a block diagram illustrating an example computer system thatmay be used in connection with various embodiments described herein.

DETAILED DESCRIPTION

Certain embodiments as disclosed herein provide for a web performancemonitoring system that enables sharing of web performance monitoringdata collected by the system between the various accounts maintained bythe system. For example, one method as disclosed herein allows for anowner account to share a portion of the data collected on behalf of theowner account with a recipient account. After reading this descriptionit will become apparent to one skilled in the art how to implement theinvention in various alternative embodiments and alternativeapplications. However, although various embodiments of the presentinvention will be described herein, it is understood that theseembodiments are presented by way of example only, and not limitation. Assuch, this detailed description of various alternative embodimentsshould not be construed to limit the scope or breadth of the presentinvention as set forth in the appended claims.

Specifically, one embodiment described herein is designed to function inthe web monitoring industry and the operating environment set forthherein. It should be understood that alternative embodiments may also bedeployed in different industries, for example in collaborative researchsystems, homeland security and other data rich industries whereinformation is collected and can be shared amongst different entities.

FIG. 1 is a network diagram illustrating an example web performancemonitoring data sharing system according to an embodiment of the presentinvention. The monitoring system which collects the website uptime andperformance data comprises three major components: a network composed ofservers 100-1 xx (referred to as the Monitoring Network 300), which eachcontain a Monitoring Probe Module (200-2 xx). The Monitoring ProbeModules connect to the Monitoring Targets 500-5 xx to collect themonitoring data. A repository 1200 stores the collected monitoring dataas well as other information, including but not limited to, the datacollection parameters. The monitoring system also comprises one or moreservers referred to as Controlling Servers 600-6 xx) which act asintermediaries between the Monitoring Network 300 and the datarepository 1200.

Additional details and information regarding the monitoring system isdescribed by Applicant in its prior filed U.S. patent application Ser.No. 12/163,659 filed 27 Jun. 2008 and U.S. patent application Ser. No.11/142,889 filed 1 Jun. 2005 and issued as U.S. Pat. No. 7,770,068, eachof which is incorporated herein by reference in its entirety.

FIG. 2 is a block diagram illustrating a web performance monitoringaccount 803 according to an embodiment of the present invention. The webperformance monitoring account 803, is a collection of monitoringmodules 700-7 xx. An account 803 can store a multiple number ofmonitoring modules 700-7 xx, as well as additional information thosemodules have in common. The account 803 allows access to monitoringmodules 700-7 xx, their data 900-9 xx, as well as to a collection oftools used to analyze, correlate, and provide reports on the data. Themonitoring system can contain a large number of such accounts.

FIG. 3 is a block diagram illustrating a web performance monitoringmodule 8002, according to an embodiment of the present invention. Theparameters 7002 for collecting the monitoring data as well as thecollected monitoring data 7001 itself, along with other data 7004 (suchas the information of the person to be contacted in case a monitoringprobe, e.g. 200, detects a problem with a monitoring target, e.g. 500,)are stored in an associated fashion by a web performance monitoringmodule, or monitoring module 8002 for short. Each account can contain alarge number of such monitoring modules.

In one embodiment, the web performance monitoring system includes avariety of modules and tools that can be used by the various accountsfor analyzing the collected monitoring data. These modules and toolsinclude, but are not limited to, dash-boarding, graphing, viewing datacollection logs, running diagnostics, etc.

Using the description above for FIGS. 1-3 as one embodiment in which thesharing of web monitoring data can be implemented, the followingdescription of FIGS. 1-5 describe an operating environment and contextfor sharing of web monitoring data according to one embodiment.

Turning now to FIG. 4, a block diagram illustrating data sharing asperformed within a controlling server is described according to anembodiment of the present invention. In the illustrated embodiment, whatis shown is a system and a process for allowing a monitoring account 800to provide data access to another monitoring account 801 via a sharingmodule 1000. This sharing is accomplished even though the accounts can,and often will be, completely independent in terms of data collectionparameters, collected monitoring data, as well as rights to view andmodify the data collection parameters. In the illustrated embodiment,the process comprises four steps that are collectively described inconnection with FIGS. 1, 4, 5, 6, 7 and 8. Note that the various stepscan occur in any order, although described in this particular sequenceto illustrate an example of the sharing mechanism and process accordingto one embodiment.

FIG. 5 is a flow diagram illustrating an example of the process ofsharing website uptime and performance data between two monitoringaccounts according to an embodiment of the present invention. In oneembodiment, this process can be carried out by the web monitoring systempreviously described with respect to FIG. 1. In this description, theaccount that is providing the data access will be known as the dataowner account 800, whereas the account that is receiving the data accesswill be known as the data recipient account 801.

Initially, in step 1 a recipient account to which web monitoring datawill be shared is identified. In one embodiment, to identify a recipientaccount 801 to provide web monitoring data to, the data owner account800 uses a unique identifier 8002 of the data recipient account 801.Accounts are uniquely defined in the system by a string of characters.This string of characters can comprise a randomly generated username, aselected username, an e-mail address, etc., and can include numbers,letters, and other characters. The string of characters may be referredto herein as a username. The easiest method of picking an account 801 toprovide data access to is by providing the username of that account tothe monitoring system. Referring briefly back to FIG. 4, the monitoringsystem is then able to associate the owner account 800 with therecipient account 801 and will establish a share 8300 between the twoaccounts.

Should the recipient account 801 not yet exist, the owner account 800can provide an email address associated with intended data recipient 401(FIG. 1) and the monitoring system sends out an email invitation to thespecified email address. The invitation email provides instructions forthe creation of the recipient account 801. Once the recipient account801 is created, the share 8300 between the two accounts will beautomatically created, and data sharing is allowed and may proceed.

Once the data share 8300 is created to provide a logical link betweenthe data owner account and the data recipient account, the sharingparameters 8400 associated with that link are stored as part of the datashare 8300 data structure. The sharing parameters 8400 specify theproperties of the share, including but not limited to, what type of datais shared, how much data the recipient account 801 has access to, aswell as the operations and tools the recipient account is allowed toperform on the data.

FIG. 8 is a block diagram detailing an example of a data share 8300between two accounts, as well as the sharing parameters 8400 associatedwith the data share 8300, according to an embodiment of the presentinvention.

Referring back to FIG. 5, once the identify of the recipient account hasbeen established, the data to be shared with the recipient account isidentified, as shown in step 2. For example, once the data share 8300between two accounts has been created, the next step is selecting thedata that the owner account 800 will make available to the recipientaccount 801. In one embodiment, the data owner account 800 chooses amonitoring module 8002 to share with the data recipient account 801.Although it is possible for the data owner account 800 to choosemultiple monitoring modules and configure sharing for themsimultaneously, a single monitoring module is used in this example forsimplicity.

The data contained by a monitoring module 8002 can be very diverse anddepends on the data collection parameters 7002. One example breakdown ofmonitoring data is provided below. The description of the breakdown ofdata provided below is intended to serve only as an example of oneembodiment and shall not serve to limit the invention to this particulartype of breakdown. In the example embodiment, the data owner account 800can choose all or a subset of the monitoring data to provide to therecipient account 801.

Data Collection Parameters 7002. The parameters specify how often amonitoring target 500 is to be examined by a monitoring probe 200, whatthe monitoring probe will record from the target, as well as whatconditions constitute a problem or cause a monitoring entry related tothe monitoring target. Common parameters include, but are not limitedto, target status (e.g. online or offline), target load time, target DNSlookup time and target timeout thresholds. Additional parameters mayalso be used.

Collected Monitoring Data 7001. This is the data collected by amonitoring probe 200 while this particular monitoring module 8002 hasbeen active, and can include recent monitoring data, as well ashistorical monitoring data, and is a record of whether or not the targethas conformed to the data collection parameters 7002 each time it wasexamined by a monitoring probe 200.

Administrative Data 7003. This data may be needed by a monitoring probe200 to authenticate itself to a monitoring target 500. An exampleincludes probing a website which requires a set of credentials, such asa username and password, for access. If the probe must examine the sitecontent which is protected, the probe must present a set of credentialsto the target for authentication.

Other Data 7004. This includes other data that may be associated withthe monitoring module 8002, including but not limited to, contactinformation in case the probe detects an error, as well as escalationprocedures in case the error persists for a predetermined period oftime.

Next, in step 3 permissions are assigned to the data. In one embodiment,once the data to be shared has been identified, the owner account 800can specify the types of operations the recipient account 801 canperform on the data and the types of tools and utilities that therecipient account may use to interrogate the data.

Advantageously, the permissions scheme for specifying the types ofoperations the receiving account can perform on the data is flexible,providing customizable levels of security and access control. Theflexibility of the scheme allows for the definition of multiple levelsof security. For example, in one embodiment there may be security levels1 through N, with each level providing greater access than the precedinglevel. In such an embodiment, increasing levels of security allow moreoperations to be performed on the data. The description of the securityscheme provided below comprises three levels (1 through 3). Thisdescription is provided only as an example and is not intended to limitthe number of security levels that can be supported by this scheme orthe permissions flexibility of each level.

Level 1—Restricted Read Only. In this mode, the recipient account 801 isonly allowed to see a portion of the data type that is being shared. Oneexample restriction is limiting the amount of historical status of thecollected monitoring data 7001 the recipient account 801 is allowed toview, e.g., from 1 year to 6 months. Another example would be to limitthe viewing of the data collection parameters 7002 to only a subset ofthose parameters. Another example would be to allow access to themonitoring target load times but not to the monitoring target's DNSlookup times. Other limitations can also be employed.

Even with the limitations in place for level 1 security, the recipientaccount 801 is able to analyze the data via certain tools normallyavailable for data analysis, including viewing graphs, viewing thecurrent status, viewing the description of the service, dash-boarding,and other utilities in accordance with the functionality provided atlevel 1 security.

Level 2—Read Only Access. In this mode, the recipient account 801 isallowed to view all the collected data 7001, as well as the datacollection parameters 7002, but is not allowed to modify the datacollection parameters. Even with the limitations in place for level 2security, the recipient account 801 is able to analyze the data viacertain tools normally available for data analysis in accordance withthe functionality provided at level 2 security.

Level 3—Full Access (Read/Write). In this mode, the recipient account801 is allowed to work with the data in the same fashion as the owneraccount 800, including using the full suite of tools to perform analysisoperations on the data as the owner account 800. For example, therecipient account 801 is able to view the collected data and analyze itusing any of the tools provided with a monitoring account. At thissecurity level, the recipient account is also allowed to view and modifythe administrative data 7003.

Turning now to step 4 of FIG. 5, in this step the data is delivered tothe recipient account 801. For example, once the owner account 800 hasidentified the data to be shared and associated a level of permissionswith that data, the sharing module 8200 is notified. Next, the sharingmodule 8200 creates a share 8300. The Share 8300 contains sharingparameters 8400, which comprise a reference to the owner account 800 (inthis case the unique username), a reference to the recipient account801, a list of the type of data that has been shared, as well as thelevel of permissions associated with the shared data. An example shareis illustrated in FIG. 8.

Once a share 8300 has been created and the parameters 8400 established,the recipient account 801 is notified by the monitoring system that newdata is available for the recipient account 801. The recipient account801 may or may not have the option to reject the shared data. Once thedata has been delivered to the recipient account 801 (or otherwise madeavailable to the recipient account 801), the tools normally used by theaccount 801 (such as graphing, reporting, etc) may be employed on theshared data, in accordance with the security level. In one embodiment,the shared data is visually and textually differentiated from therecipient account's own data to prevent confusion as to the ownership ofthe data. Additionally, the owner account 800 may optionally be notifiedof the successful creation of a share 8300 between the two accounts andwhether or not the recipient account 801 accepted or rejected the shareddata, if applicable.

With the shared data integrated into the recipient account's list ofaccessible monitoring data, the recipient account 801 can analyze andcorrelate the shared data with its own data, or with other shared datafrom other owner accounts. A recipient account 801 is able to receivedata from multiple owner accounts 800, as well as able to send andreceive data at the same time (e.g. a recipient account 801 cansimultaneously be an owner account 800, and a owner account 800 cansimultaneously be a recipient account 801, depending on the context).FIG. 9 is a block diagram illustrating a monitoring account that isacting as both a data owner and data recipient, according to anembodiment of the present invention.

Once the sharing process has been completed, the owner account 800 isable to view one or all of the recipient accounts 801 it has shared datawith, including which monitoring modules have been shared, what type ofdata has been shared (e.g. collected data 7001, data collectionparameters 7002, etc), and the permission levels associated with eachrecipient account. FIG. 6 is a block diagram illustrating the data owneraccount's view of the recipient accounts it has shared data with.

Once the sharing process has been completed, the recipient account 801is able to view all of the owner accounts 800 it has received data from,as well as information about the data that has been shared, includingthe type of shared data and the permission levels granted by each owneraccount 800. FIG. 7 is a block diagram illustrating the recipientaccount's view of the owner accounts that have shared data with it.

Turning now to FIGS. 10-12, a variety of relationship types between anowner account and a recipient account are contemplated. In oneembodiment, the mechanism used to create a data share 8300 between anowner account and a recipient account can also be used to create datashares that are one to many. For example, one owner account 800 canprovide data to multiple recipient accounts 801-8 xx. Similarly, onerecipient account 801 can be the recipient of data from multiple owneraccounts 800. FIG. 9 is a block diagram illustrating a monitoringaccount that is simultaneously acting as both a data owner and datarecipient, according to an embodiment of the present invention.

Additionally, in alternative embodiments, shared data can be organizedin a variety of ways. For example, the data sharing process describedabove is an example of a data owner account 800 sharing the data from asingle monitoring module with a single data recipient account 801. Inone embodiment, sharing the data collected by multiple monitoringmodules is accomplished by repeating the same sharing process describedabove for each monitoring module for which monitoring data is desired tobe shared. However, this approach can be tedious and time consuming andlabor intensive.

Accordingly, the monitoring system is configured to allow severalalternative types of high volume organizational methods that each makethe sharing of data easier to perform when a large number of accountsand monitoring modules are involved. In one embodiment, the methodsdescribed below can be employed as part of steps 2 and 3 that werepreviously described with respect to FIG. 5.

A first high volume technique is referred to as enumeration. FIG. 10 isa block diagram illustrating the enumeration method for organizing datato be shared, according to an embodiment of the present invention. Theenumeration method is advantageously simple. Instead of the data owneraccount choosing only one monitoring module 8002 for which to configurethe data sharing, the data owner account enumerates a list of suchmonitoring modules 8001-80 xx. Once the list is complete, the data owneraccount chooses the type of data to be shared and permissions levelsfrom the available options, and every monitoring module included in thelist will be configured for sharing with the selected options.

The owner account can then select one recipient account, or alsoenumerate a list of recipient accounts 8100 to 81 xx to share the datawith. Once the list of recipient accounts is complete, the owner accountshares all the monitoring modules identified in the list above with eachof the recipient accounts in the enumerated list of recipient accounts.

A second high volume technique is referred to as groups. FIG. 11 is ablock diagram illustrating the group method for organizing data to beshared, according to an embodiment of the present invention. In thisembodiment, the monitoring system includes the ability to associaterelated monitoring modules into logical entities called groups ofmonitoring modules, or groups for short.

As shown in FIG. 11, the owner account 810 selects a list of monitoringmodules 8011-801 x and then groups them into one or more groups ofmodules 4020-402 x. The owner account next selects the type of data tobe shared and sharing permissions for the whole group. The group levelpermissions are then applied to every individual monitoring module inthe group.

Next, the owner account selects a recipient account, and shares thewhole group. When this option is used, the recipient account willreceive access to every monitoring module in the shared group, as wellas gain access to the monitoring modules in the same associated fashion,(e.g. as a group of modules), as the owner account.

FIG. 12 is a block diagram illustrating sharing being performed withinthe group method for data organization, according to an embodiment ofthe present invention. In the illustrated embodiment, a moreencompassing organization concept is provided that includes a group ofgroups 4030. Similar to the way related monitoring modules areassociated into a group as described above with respect to FIG. 11,desired groups of modules can also be associated into a group of groups.The owner account can also provide access to monitoring data at thislevel, sharing a whole group of groups with the recipient account.

Furthermore, the nesting of groups can be applied at multiple levelssuch that an owner account can define groups of groups of groups andbeyond in order to simply and efficiently define sharable combinationsof data from individual monitoring modules and simply and efficientlyapply permissions to related groups.

Advantageously, because a hierarchy is created when grouping monitoringmodules in this way, the monitoring system provides an inheritancemechanism that allows for the access control permissions to be inheritedin accordance with the group hierarchy.

For example, the lowest level in the group hierarchy is defined as agroup of monitoring modules 4020. A group of groups 4030 encompassingthe group of modules is at the next higher level in the hierarchy, and agroup encompassing group 4030 is at yet the next higher level, and soon. In this group hierarchy, a group in a higher level in the hierarchycan further restrict permissions of modules in a group lower in thehierarchy, but cannot be more permissive than a group lower in thehierarchy.

A third high volume technique is referred to as tagging or labeling. Inone embodiment, a tag is a way of labeling a particular monitoringmodule. For example, a tag can be textual but other types of tags suchas images, can be used to label a monitoring module. In tagging, anowner account selects a list of monitoring modules to share. The owneraccount then tags the monitoring modules with several keywords.

In a first example of sharing web based monitoring data using tagging,data shares are created for each monitoring module having a particulartag. Once the owner account has a list of tagged modules, the owneraccount identifies the monitoring modules to be shared by selecting thedesired tag. Similarly, the type of permissions associated with theshared monitoring data can also be identified by selecting the desiredtag. At this point, the monitoring system creates a separate data shareas well as sharing parameters for each of the monitoring modulesassociated with the selected tag. Advantageously, this use of tags as anorganizational tool allows the mass application of sharing settings to alist of tagged modules.

In a second example of sharing web based monitoring data using tagging,a data share is created for each individual tag. In this example, oncethe monitoring modules have been tagged, a single data share is createdthat includes all of the monitoring modules that as associated with theparticular combination of tags designated by the owner account.Permissions can be similarly applied to this single share.

This is a very powerful mechanism because when additional monitoringmodules are tagged, they automatically receive the sharing parameters ofthe tag, without the owner account having to individually select themfor the data share.

Example Embodiments Example 1

A network based software application uses components distributed acrossa public or private network, components which may be provided bydifferent parties. This network based application is referred to in thisexample as a mashup. For the purposes of this example, a hypotheticalmashup called “Cold Call Assistant” is defined. The mashup uses softwarecomponents provided by salesforce.com. For each sales lead, it gathersrecent news near the geographic location of the prospect, news about thecompetition, provides a list of restaurants near the location of theprospect along with a map for directions, and the mashup provides thecurrent weather in the geographic location of the prospect. Internally,it uses data from Google local search, Google finance, Google maps,Accuweather, Dapper, and Apatar.

The owner of the mashup would like to know when his/her visitors arehaving a bad experience. The owner would like to know how often each ofthe components used by the mashup has a problem. The provider of themashup would like to track alternatives to the current components usedin the mashup, to help identify potentially better performing componentsthat may be used in the future. The provider of the mashup would alsolike to be able to show this performance monitoring information to thecomponent providers and vendors, to prove when they are having problems.

In order to accomplish this, the mashup provider signs up for a webperformance monitoring account (owner account) and employs performancemonitoring modules for each of the components that the mashup uses, suchas Google local search, Google finance, Google maps, Accuweather,Dapper, and Apatar. The mashup provider then obtains information abouteach component vendor's web performance monitoring accounts—either fromthe vendors themselves or by using their email addresses to initiate thedata sharing process described above. Upon sharing the monitoring datawith the various vendors, the vendors are then able to see the sharedmonitoring data the mashup owner account wants them to see. Accordingly,the component vendors are able to see, as provide by the mashupprovider, when a component is having performance problems.

Example 2

A hypothetical large outsourced payment processor has abehind-the-firewall service oriented architecture (“SOA”) process. Oneof the web service requests in the SOA transaction is to connect to anoutside vendor, the US Post Office. As part of this connection, theprocessor sends the US Post Office its unique account credentials,security key and a data payload including general information about anemployee's paycheck which the Post Office prints out and mails in anenvelope. When the processor gets the positive response back from thePost Office that the check was mailed, the payment processor completesits SOA process and ends with a confirmation number.

a) the payment processor uses performance monitoring accounts andservices, and has each step of the SOA process monitored as a part of aweb service transaction service.

The Post Office also uses performance monitoring accounts, and they havetheir three step SOA process monitored which accepts the requests fromcustomers and connects to the printer and envelope stuffer to completethe internal process.

c) The Post Office has shared a group status indicator for theircomplete SOA transaction with the Post Office, showing the operatingstatus of a group of performance monitoring services.

d) The outsourced payment processor monitors the same basicfunctionality but in a different way—as a discrete transaction from theend user perspective.

e) The payment processor desires to associate its monitoring status withthe Post Office's group-level monitoring status as a related monitor. Inthis way the processor can determine: (1) if a problem is reported byits performance monitoring service and a problem is reported by the PostOffice performance monitoring service then the processor knows that thePost Office is aware of the problem and is hopefully already working onit; (2) if a warning is reported by the processor's performancemonitoring service, and no problem is reported by the Post Office'smonitoring service, the processor knows that most likely the problem ison the Post Office end, but they do not perceive it as a problem and arenot actively working on it. This way the processor can notify the PostOffice; and (3) if the processor sees a problem reported by the PostOffice's monitoring service, and no warnings or problems are reported byits own monitoring service, the processor would know that most likelythe Post Office is fine and is not working on any problem, and theprocessor may be the source of the problem. In this way the processormay need to undertake internal investigation.

In order to accomplish this, the processor asks the Post Office toinitiate the process described above for sharing website uptime andperformance data, and upon receipt of their shared data, the processorcan accomplish everything stated in step (e) above.

FIG. 13 is a block diagram illustrating an example computer system 550that may be used in connection with various embodiments describedherein. For example, the computer system 550 may be used in conjunctionwith a monitoring server, controlling server, data owner, datarepository, or monitoring target previously described with respect toFIG. 1. However, other computer systems and/or architectures may beused, as will be clear to those skilled in the art.

The computer system 550 preferably includes one or more processors, suchas processor 552. Additional processors may be provided, such as anauxiliary processor to manage input/output, an auxiliary processor toperform floating point mathematical operations, a special-purposemicroprocessor having an architecture suitable for fast execution ofsignal processing algorithms (e.g., digital signal processor), a slaveprocessor subordinate to the main processing system (e.g., back-endprocessor), an additional microprocessor or controller for dual ormultiple processor systems, or a coprocessor. Such auxiliary processorsmay be discrete processors or may be integrated with the processor 552.

The processor 552 is preferably connected to a communication bus 554.The communication bus 554 may include a data channel for facilitatinginformation transfer between storage and other peripheral components ofthe computer system 550. The communication bus 554 further may provide aset of signals used for communication with the processor 552, includinga data bus, address bus, and control bus (not shown). The communicationbus 554 may comprise any standard or non-standard bus architecture suchas, for example, bus architectures compliant with industry standardarchitecture (“ISA”), extended industry standard architecture (“EISA”),Micro Channel Architecture (“MCA”), peripheral component interconnect(“PCI”) local bus, or standards promulgated by the Institute ofElectrical and Electronics Engineers (“IEEE”) including IEEE 488general-purpose interface bus (“GPIB”), IEEE 696/S-100, and the like.

Computer system 550 preferably includes a main memory 556 and may alsoinclude a secondary memory 558. The main memory 556 provides storage ofinstructions and data for programs executing on the processor 552. Themain memory 556 is typically semiconductor-based memory such as dynamicrandom access memory (“DRAM”) and/or static random access memory(“SRAM”). Other semiconductor-based memory types include, for example,synchronous dynamic random access memory (“SDRAM”), Rambus dynamicrandom access memory (“RDRAM”), ferroelectric random access memory(“FRAM”), and the like, including read only memory (“ROM”).

The secondary memory 558 may optionally include a hard disk drive 560and/or a removable storage drive 562, for example a floppy disk drive, amagnetic tape drive, a compact disc (“CD”) drive, a digital versatiledisc (“DVD”) drive, etc. The removable storage drive 562 reads fromand/or writes to a removable storage medium 564 in a well-known manner.Removable storage medium 564 may be, for example, a floppy disk,magnetic tape, CD, DVD, etc.

The removable storage medium 564 is preferably a computer readablemedium having stored thereon computer executable code (i.e., software)and/or data. The computer software or data stored on the removablestorage medium 564 is read into the computer system 550 as electricalcommunication signals 578.

In alternative embodiments, secondary memory 558 may include othersimilar means for allowing computer programs or other data orinstructions to be loaded into the computer system 550. Such means mayinclude, for example, an external storage medium 572 and an interface570. Examples of external storage medium 572 may include an externalhard disk drive or an external optical drive, or and externalmagneto-optical drive.

Other examples of secondary memory 558 may include semiconductor-basedmemory such as programmable read-only memory (“PROM”), erasableprogrammable read-only memory (“EPROM”), electrically erasable read-onlymemory (“EEPROM”), or flash memory (block oriented memory similar toEEPROM). Also included are any other removable storage units 572 andinterfaces 570, which allow software and data to be transferred from theremovable storage unit 572 to the computer system 550.

Computer system 550 may also include a communication interface 574. Thecommunication interface 574 allows software and data to be transferredbetween computer system 550 and external devices (e.g. printers),networks, or information sources. For example, computer software orexecutable code may be transferred to computer system 550 from a networkserver via communication interface 574. Examples of communicationinterface 574 include a modem, a network interface card (“NIC”), acommunications port, a PCMCIA slot and card, an infrared interface, andan IEEE 1394 fire-wire, just to name a few.

Communication interface 574 preferably implements industry promulgatedprotocol standards, such as Ethernet IEEE 802 standards, Fiber Channel,digital subscriber line (“DSL”), asynchronous digital subscriber line(“ADSL”), frame relay, asynchronous transfer mode (“ATM”), integrateddigital services network (“ISDN”), personal communications services(“PCS”), transmission control protocol/Internet protocol (“TCP/IP”),serial line Internet protocol/point to point protocol (“SLIP/PPP”), andso on, but may also implement customized or non-standard interfaceprotocols as well.

Software and data transferred via communication interface 574 aregenerally in the form of electrical communication signals 578. Thesesignals 578 are preferably provided to communication interface 574 via acommunication channel 576. Communication channel 576 carries signals 578and can be implemented using a variety of wired or wirelesscommunication means including wire or cable, fiber optics, conventionalphone line, cellular phone link, wireless data communication link, radiofrequency (RF) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is storedin the main memory 556 and/or the secondary memory 558. Computerprograms can also be received via communication interface 574 and storedin the main memory 556 and/or the secondary memory 558. Such computerprograms, when executed, enable the computer system 550 to perform thevarious functions of the present invention as previously described.

In this description, the term “computer readable medium” is used torefer to any media used to provide computer executable code (e.g.,software and computer programs) to the computer system 550. Examples ofthese media include main memory 556, secondary memory 558 (includinghard disk drive 560, removable storage medium 564, and external storagemedium 572), and any peripheral device communicatively coupled withcommunication interface 574 (including a network information server orother network device). These computer readable mediums are means forproviding executable code, programming instructions, and software to thecomputer system 550.

In an embodiment that is implemented using software, the software may bestored on a computer readable medium and loaded into computer system 550by way of removable storage drive 562, interface 570, or communicationinterface 574. In such an embodiment, the software is loaded into thecomputer system 550 in the form of electrical communication signals 578.The software, when executed by the processor 552, preferably causes theprocessor 552 to perform the inventive features and functions previouslydescribed herein.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(“ASICs”), or field programmable gate arrays (“FPGAs”). Implementationof a hardware state machine capable of performing the functionsdescribed herein will also be apparent to those skilled in the relevantart. Various embodiments may also be implemented using a combination ofboth hardware and software.

Furthermore, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and method stepsdescribed in connection with the above described figures and theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled persons can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the invention. In addition, the grouping of functions within amodule, block, circuit or step is for ease of description. Specificfunctions or steps can be moved from one module, block or circuit toanother without departing from the invention.

Moreover, the various illustrative logical blocks, modules, and methodsdescribed in connection with the embodiments disclosed herein can beimplemented or performed with a general purpose processor, a digitalsignal processor (“DSP”), an ASIC, FPGA or other programmable logicdevice, discrete gate or transistor logic, discrete hardware components,or any combination thereof designed to perform the functions describedherein. A general-purpose processor can be a microprocessor, but in thealternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

Additionally, the steps of a method or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module can reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, harddisk, a removable disk, a CD-ROM, or any other form of storage mediumincluding a network storage medium. An exemplary storage medium can becoupled to the processor such the processor can read information from,and write information to, the storage medium. In the alternative, thestorage medium can be integral to the processor. The processor and thestorage medium can also reside in an ASIC.

The above description of the disclosed embodiments is provided to enableany person skilled in the art to make or use the invention. Variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles described herein can beapplied to other embodiments without departing from the spirit or scopeof the invention. Thus, it is to be understood that the description anddrawings presented herein represent a presently preferred embodiment ofthe invention and are therefore representative of the subject matterwhich is broadly contemplated by the present invention. It is furtherunderstood that the scope of the present invention fully encompassesother embodiments that may become obvious to those skilled in the artand that the scope of the present invention is accordingly not limited.

1. A technical system for sharing web monitoring data collected by a webmonitoring service provider on behalf of a plurality of web monitoringaccounts, the system comprising: a plurality of monitoring serversconfigured to monitor a target via a data communication network togenerate and store web monitoring data; a controlling servercommunicatively coupled via a data communication network with theplurality of monitoring servers, the controlling server having access tosaid stored web monitoring data, wherein the controlling server hosts aplurality of monitoring accounts; a sharing module executable on thecontrolling server, the sharing module configured to maintain sharingdata related to the plurality of monitoring accounts, wherein thecontrolling server is further configured to receive a request for sharedweb monitoring data and grant or deny said request in accordance withsaid sharing data.